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1.Jato 1.1 


1.0. to 1.1a 


On 17" October 1996 the IrDA Board voted to accept the Technical 
Committee’s recommendation that Draft Version 1.1a of the Tiny TP 
specification be adopted as Version 1.1 of that specification. 


The use of an explicit zero-valued MaxSduSize parameter during TTP 
connection establishment has been deleted to enable LITE implementations of 
Tiny TP that do not implement SAR to merely test for the presence or absence 
of the MaxSduSize parameter rather the having to inspect its value for zero as 
well. 


As a consequence the overloading of the MaxSduSize parameter to tag byte- 
stream or sequenced packet semantics during connection establishment, 
suggested in Appendix A Section 4.3 has been removed. 


Clarification has been added to section 2.3.2.1 that clearly states that the 
MaxSduSize parameter is strictly applied to the size of SDUs exchanged 
between peer TTP clients. 
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INFRARED DATA ASSOCIATION (IrDA) - NOTICE TO THE TRADE - 


SUMMARY: 


Following is the notice of conditions and understandings upon which this document is made available to 
members and non-members of the Infrared Data Association. 


e Availability of Publications, Updates and Notices 

e Full Copyright Claims Must be Honored 

¢ Controlled Distribution Privileges for IrDA Members Only 
e¢ Trademarks of IrDA - Prohibitions and Authorized Use 

e No Representation of Third Party Rights 

e Limitation of Liability 

e Disclaimer of Warranty 


e Product Testing for IrDA Specification Conformance 


IrDA PUBLICATIONS and UPDATES: 


IrDA publications, including notifications, updates, and revisions, are accessed electronically by IrDA 
members in good standing during the course of each year as a benefit of annual IrDA membership. 
Electronic copies are available to the public on the IrDA web site located at irda.org. Requests for 
publications, membership applications or more information should be addressed to: Infrared Data 
Association, P.O. Box 3883, Walnut Creek, California, U.S.A. 94598; or e-mail address: info@irda.org; or by 
calling John LaRoche at (510) 943-6546 or faxing requests to (510) 934-5600. 


COPYRIGHT: 


1. Prohibitions: IrDA claims copyright in all IrDA publications. Any unauthorized reproduction, distribution, 
display or modification, in whole or in part, is strictly prohibited. 


2. Authorized Use: Any authorized use of IrDA publications (in whole or in part) is under NONEXCLUSIVE 
USE LICENSE ONLY. No rights to sublicense, assign or transfer the license are granted and any attempt to 
do so is void. 


TRADEMARKS: 


1. Prohibitions: IrDA claims exclusive rights in its trade names, trademarks, service marks, collective 
membership marks and certification marks (hereinafter collectively "trademarks"), including but not limited to 
the following trademarks: INFRARED DATA ASSOCIATION (wordmark alone and with IR logo), IrDA 
(acronym mark alone and with IR logo), IR logo, IR DATA CERTIFIED (composite mark), and MEMBER IrDA 
(wordmark alone and with IR logo). Any unauthorized use of IrDA trademarks is strictly prohibited. 


2. Authorized Use: Any authorized use of a IrDA collective membership mark or certification mark is by 
NONEXCLUSIVE USE LICENSE ONLY. No rights to sublicense, assign or transfer the license are granted 
and any attempt to do so is void. 
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NO REPRESENTATION of THIRD PARTY RIGHTS: 


IrDA makes no representation or warranty whatsoever with regard to IrDA member or third party ownership, 
licensing or infringement/non-infringement of intellectual property rights. Each recipient of IrDA publications, 
whether or not an IrDA member, should seek the independent advice of legal counsel with regard to any 
possible violation of third party rights arising out of the use, attempted use, reproduction, distribution or 
public display of IrDA publications. 


IrDA assumes no obligation or responsibility whatsoever to advise its members or non-members who receive 
or are about to receive IrDA publications of the chance of infringement or violation of any right of an IrDA 
member or third party arising out of the use, attempted use, reproduction, distribution or display of IrDA 
publications. 


LIMITATION of LIABILITY: 


BY ANY ACTUAL OR ATTEMPTED USE, REPRODUCTION, DISTRIBUTION OR PUBLIC DISPLAY OF 
ANY IrDA PUBLICATION, ANY PARTICIPANT IN SUCH REAL OR ATTEMPTED ACTS, WHETHER OR 
NOT A MEMBER OF IrDA, AGREES TO ASSUME ANY AND ALL RISK ASSOCIATED WITH SUCH ACTS, 
INCLUDING BUT NOT LIMITED TO LOST PROFITS, LOST SAVINGS, OR OTHER CONSEQUENTIAL, 
SPECIAL, INCIDENTAL OR PUNITIVE DAMAGES. IrDA SHALL HAVE NO LIABILITY WHATSOEVER FOR 
SUCH ACTS NOR FOR THE CONTENT, ACCURACY OR LEVEL OF ISSUE OF AN IrDA PUBLICATION. 


DISCLAIMER of WARRANTY: 


All IrDA publications are provided "AS IS" and without warranty of any kind. IrDA (and each of its members, 
wholly and collectively, hereinafter "IrDA") EXPRESSLY DISCLAIM ALL WARRANTIES, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 
FITNESS FOR A PARTICULAR PURPOSE AND WARRANTY OF NON-INFRINGEMENT OF 
INTELLECTUAL PROPERTY RIGHTS. 


IrDA DOES NOT WARRANT THAT ITS PUBLICATIONS WILL MEET YOUR REQUIREMENTS OR THAT 
ANY USE OF A PUBLICATION WILL BE UN-INTERRUPTED OR ERROR FREE, OR THAT DEFECTS WILL 
BE CORRECTED. FURTHERMORE, IrDA DOES NOT WARRANT OR MAKE ANY REPRESENTATIONS 
REGARDING USE OR THE RESULTS OR THE USE OF IrDA PUBLICATIONS IN TERMS OF THEIR 
CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. NO ORAL OR WRITTEN PUBLICATION 
OR ADVICE OF A REPRESENTATIVE (OR MEMBER) OF IrDA SHALL CREATE A WARRANTY OR IN ANY 
WAY INCREASE THE SCOPE OF THIS WARRANTY. 


LIMITED MEDIA WARRANTY: 


IrDA warrants ONLY the media upon which any publication is recorded to be free from defects in materials 
and workmanship under normal use for a period of ninety (90) days from the date of distribution as 
evidenced by the distribution records of IrDA. IrDA's entire liability and recipient's exclusive remedy will be 
replacement of the media not meeting this limited warranty and which is returned to IrDA. IrDA shall have no 
responsibility to replace media damaged by accident, abuse or misapplication. ANY IMPLIED WARRANTIES 
ON THE MEDIA, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
PARTICULAR PURPOSE, ARE LIMITED IN DURATION TO NINETY (90) DAYS FROM THE DATE OF 
DELIVERY. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS, AND YOU MAY ALSO HAVE 
OTHER RIGHTS WHICH VARY FROM PLACE TO PLACE. 


COMPLIANCE and GENERAL: 
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Membership in IrDA or use of IrDA publications does NOT constitute IrDA compliance. It is the sole 
responsibility of each manufacturer, whether or not an IrDA member, to obtain product compliance in 
accordance with IrDA Specifications. 


All rights, prohibitions of right, agreements and terms and conditions regarding use of IrDA publications and 
IrDA rules for compliance of products are governed by the laws and regulations of the United States. 
However, each manufacturer is solely responsible for compliance with the import/export laws of the countries 
in which they conduct business. The information contained in this document is provided as is and is subject 
to change without notice. 
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1. Introduction 


Whilst IrLAP provides a flow-control mechanism between peer IrLAP [1] entities, the introduction of 
multiplexed channels above IrLAP by IrLMP LM-MUX [2] introduces a problem. Reliance on IrLAP 
to provide flow-control for a multiplexed channel can result in dead-locks if the consumption of data 
from one multiplexed channel is dependent on data flowing in an adjacent multiplexed channel. 
Conversely, if inbound data on a multiplexed channel cannot be consumed and the underlying 
IrLAP connection cannot be flow-controlled off due to the possibility of deadlock, inbound data 
(freshly arrived or buffered) must be discarded in the event of buffer exhaustion. Sadly this reduces 
the reliable delivery service provided by IrLAP to a best effort delivery service provided by IrLMP 
LM-MUX (when multiple multiplexed channels are in operation). 


There are at least two possible solutions for restoring a reliable delivery service above IrLMP 
LM-MUX. 


1. Provide a per application stream flow-control mechanism above LM-MUX between peer 
application entities. This ensures that there is always sufficient buffer space available to 
accomodate in-bound application data. OR 


2. Provide a per application stream retransmission mechanism above LM-MUX that recovers from 
the loss of data that arises if inbound buffering become exhausted. 


The Tiny TP protocol detailed in this document provides just: 
e independently flow controlled transport connections 

¢ segmentation and reassembly 

1.1 References 


[2] “Serial Infrared Link Access Protocol”, IrLAP, Version 1.0, Infrared Data Association, 
June 1994 


[4] | “Link Management Protocol”, IrLMP, Version 1.0, Infrared Data Association, August 1994 
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2. Elements of Procedure 


2.1 Tiny TP Service Access Point Addresses. 


Since each Tiny TP Service Access Point (TTPSAP) is accessible through one and only one IrLMP 
LM-MUX LSAP the syntax of a TTPSAP address is identical to that of an IrL_MP LSAP address. 
Namely: 


<TTSAP Address> = <LSAP Address> = <DeviceAddress><LSAP-SEL> 
Thus a TTSAP is identified by the address of the LSAP through which it is accessed. 


Similarly, a TTP connection (or TTP connection endpoint) is identified by the pair of TTPSAP 
addresses at each end of the connection. 


2.2 Tiny TP Service Primitives 


2.2.1 TTP_Connect 


TTP_Connect.request ( Called TTPSAP, 
Requested QoS, 
Calling MaxSduSize 
Calling UserData ) 


TTP_Connect.indication( Calling TTPSAP, 
Resultant QoS, 
Calling MaxSduSize 
Calling UserData ) 


TTP_Connect .response ( Calling TTPSAP, 
Called MaxSduSize, 
Called UserData ) 


TTP_Connect.confirm ( Called TTPSAP, 
Resultant QoS, 
Called MaxSduSize 
Called UserData) 


TTPSAP A reference to a TTPSAP which is also an implicit reference 
to the corresponding IrLMP LM-MUX LSAP. 

QoS IrLMP/IrLAP Quality of Service parameters. 

MaxSduSize The maximum size of the UserData field, in bytes, that may 


delivered in a TTP_Data. indication primitive at the 
Calling and Called ends of the TTP connection respectively. 
The Calling and Called values for MaxSduSize are specified 
independently and may differ. 


A value of zero disables segmentation and reassembly (SAR). 
The UserData field submitted in TTP_Data. request must 
then fit within a single Data TTP-PDU whose maximum size is 
determined by IrLAP negotiation. 
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UserData Calling UserData is passed from the entity initiating a TTP 
connection to the entity that should respond to an incomming 
TTP connection request. Likewise, Called UserData is 
passed back from the responding entity to the initiating entity. 


The total size of the Connect TTP-PDUs transferred during 
connection establishment is limited by the size negotiated for 
the underlying IrLAP connection. Currently the maximum size 
of the Parameters field of the Connect TTP-PDU is 6 bytes, 
therefore a connect UserData field of 52 bytes’ or less can 
always be transferred during connection establishment. 


Typically this might be used as a signature field to help decide 
whether to accept the connection; parameter negotiation 
between TTP clients; or simply to piggyback a small amount 
of data. 


This service is used to establish a TTP-connection between two IrLMP LSAPs. They are similar to 
the corresponding IrLMP LM-MUX LM-Connect primitives. 


2.2.2 TTP_Disconnect 


TTP_Disconnect. request (UserData) 


TTP_Disconnect.indication (Reason, UserData) 


Reason Disconnect Reason: passed through from IrLMP. Values other 
than UserRequested indicate that the connection was 
terminated by the TTP service provider rather than by the 
peer TTP client entity. 


UserData Present only if the reason field specifies UserRequested 
Up to 60 bytes of data accompanying the disconnect. 


Typically this might be used to carry application specific 
diagnostic/reason information concerning the disconnect. 


This service is used to: reject incoming TTP connections; terminate a TTP connection; and to 
indicate both the normal and abnormal termination of a TTP connection. 


The TTP_Disconnect service primitives are mapped to the corresponding IrLMP[4] 
LM_Disconnect service primitives. However, a TTP_Disconnect.indication, generated in 
response to the invocation (by IrLMP) of an LM_Disconnect.indication, is schedule to occur 
after all preceding data received on the TTP connection has been passed to the local TTP client 
(with the exception of any partially reassembled TIP SDUs). Likewise, a 
LM_Disconnect. request, generated in response to the invocation of 
TTP_Disconnect.request by the local TTP client, is schedule after all preceding data for the 
TTP connection received from the local TTP client has been transferred to IrLMP. 


"The minimum IrLAP maximum data size is 64 bytes. The Connect LM-PDU has a 4 byte header. 
If a maximum length MaxSduSize parameter is present then the Connect TTP-PDU currently has a 
maximum header length of 8 bytes. 64-4-8=52 
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2.2.3 TTP_Data 


TTP_Data.request (UserData) 
TTP_Data.indication (UserData, Status) 


UserData This is the TTP Client Service Data Unit (SDU) that is 
exchanged between TTP Clients. 


If SAR is active then the size of the UserData field submitted 
inthe . request primitive must not exceed the MaxSduSize 
indicated in the TTP_Connect.indication or 
TTP_Connect.confirm primitive that established the 
connection. 


Likewise the size of UserData field delivered using the 

. indication primitive may not exceed the MaxSduSize 
indicated in the TTP_Connect.request or 
TTP_Connect. response primitive that established the 
connection. 


If SAR is inactive, then the size of the UserData field is 
constrained to fit within a single Data TTP-PDU. 


Status Delivery Status may take the following values: 


OK: If the reassembly process is inactive or 
has successfully reassembled the inbound 
SDU. 


Truncated: If the reassembly process has truncated 
the inbound SDU because its exceeds the 
agreed size. 


TTP SDUs submitted by the invocation of TTP_Data.request are delivered to the corresponding 
peer by the invocation of TTP_Data.indication. The TTP_LocalFlow service is used to 
suspend and resume the generation of TTP_Data. indication service primitives. 


2.2.4 TTP_UData 
TTP_UData. request (UserData) 
TTP_UData.indication (UserData) 


Send data unreliably and without flow control. There is no guarantee that data sent in this manner 
will be delivered. These service primitives are mapped directly to the corresponding LM-UData 
service primitives for the underlying LSAP-connection. The size of the UserData field is 
constrained to fit a single Data LM-PDU used to convey the UserData (SDU). 
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2.2.5 TTP_LocalFlow 
TTP_LocalFlow. request (Flow=on|off) 


Flow F low=on enables the flow of received TTP SDUs to pass 
from the receiving TTP entity to the local TTP client via the 
local invocation of TTP_Data. indication primitives. 


Flow=of £ halts the flow of TTP SDUs to the local TTP client. 
Inbound data is held backlogged within the receiving TTP 
entity which may apply backpressure to halt the data flow at 
the sending peer TTP entity. 


This service is used to control the flow of received TTP SDUs between the receiving TTP entity 
and its local client. 


2.3 Tiny TP Protocol Data Units 


2.3.1 Data TTP-PDUs 


Data TTP-PDUs are carried in the UserData field of IrLMP LM-MUX Data LM-PDUs. Hence, Data 
TTP-PDUs are passed as the UserData parameter in IrL_MP LM_Data service primitives 


These are the only IrLMP service primitives used to carry Data TTP-PDUs. 


1 byte 0-(IrLAPmax-3) bytes 
| 
M DeltaCredit UserData 
Bit: 7 6-0 


Figure 2.1 Data TTP-PDU 
M The More bit. 


Only significant if SAR has been specified by the use of non- 
zero MaxSduSize during connection establishment. 


When set indicates that the UserData field does not contain 
the last segment of a segmented TTP-SDU. 


When clear indicates that the UserData field contains the final 
segment of a segmented TTP-SDU. 


For Dataless Data TTP-PDUs (see below) the M bit MUST be 
sent as 0 and is ignored on reception. 


DeltaCredit Specifies the number (0-127) of additional Data-Carrying Data 
TTP-PDUs that may be sent in the reverse direction. 


A Data-Carrying Data TTP-PDU carries 1 or more octets of 
UserData 


A Dataless Data TTP-PDU has a zero length UserData field. 


It is always permissible to send a dataless Data TTP-PDU in 
order to advance credit to the peer TTP Entity. 
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UserData If SAR is in operation then this field carries a segment of a 
segmented TTP-SDU. 


It is recommended that all segments of a segmented TTP-SDU 
except the last should fill outbound Data TTP-PDUs*. 


When SAR is not in operation TTP requires that TTP-SDUs fit 
within a single Data TTP-PDU. 


2.3.2 Connect TTP-PDUs 


Connect TTP-PDUs are exchanged during connection establishment and are carried in the 
UserData field of Connect LM-PDUs and Connect Confirm LM-PDUs. Hence Connect TTP-PDUs 


are passed as UserData in the IrLMP LM_Connect service primitives. 


There are two forms of Connect TTP-PDU, once that carries a Parameters field and one that 
does not. 


1 byte 0 to 59 bytes 


InitialCredit UserData 


1 byte 0 to (59-(x+1)) bytes 


InitialCredit Parameters UserData 


x bytes 


Pvalue 


Pi [PL PL | PV 


1st Parameter | 2nd Parameter 
(if present) 


Figure 2.3 Parameter Carrying Connect TTP-PDU 


* The maximum size of an outbound PDU may be constrained smaller than that imposed by IrLAP 
negotiation due to local buffer management considerations 
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P When set specifies that a variable length Parameters field 
follows the InitialCredit field (Figure 2.3). 


When clear specifies that the Parameters field is absent 
(Figure 2.2) and that parameters should assume their default 
values. 


InitialCredit Specifies the initial number (0-127) of Data-Carrying Data 
TTP-PDUs that may be sent in the reverse direction. . 


Parameters A variable length field composed of two subfield, a single byte 
Plen that indicates the size in bytes (0-255) of the second sub- 
field Pvalue. Pvalue contains a list of tuples of the form PT, 
PL and PV. PI and PL are each a single byte in size and 
identify the parameter being carried and specify the length of 
the value carried in its Pv field respectively. The Pv field 
carries the parameter value and its interpretation depends on 
the value of PI. This tuple mechanism is identical to that used 
for IrLAP parameter negotiation and for the IrCOMM control 
channel. 


If there are N parameters then the value of Plen is: 
N 
Plen = ¥.(2+PLx) 


x=1 


UserData The remainder of the Connect LM-PDU used to carry the 
Connect TTP-PDU carries UserData that is exchanged 
between TTP clients during connection establishment. 


Implicitly this field carries a single unsegmented TTP-SDU, ie. 
it DOES NOT carry the first segment of an SDU that is 
continued in subsequent Data TTP-PDUs. 


Currently the maximum size of the Parameters field is 7 
bytes therefore a UserData field of up to 52 bytes may always 
be transferred. Future revisions of this standard may reduce 
this value. 


2.3.2.1 Connect TTP-PDU Parameters 


Tiny TP curently defines only one parameter that may be carried in the Parameters field of a 
Connect TTP-PDU 


Parameter Name: MaxSduSize 
PI Value: 0x01 
PL Range: 0x00-0x04 


Value Semantics: The maximum size of the UserData field, in bytes, that may delivered in a 
TTP_Data.indication primitive at the end of the connection sending the 
parameter. 


Non-zeroed values of MaxSduSize indicate the maximum TTP-SDU sizes that 
receiving TTP clients are prepared to accept. The value of this parameter 
should be strictly applied even if it is smaller than that indicated by the 
appropriate IrLAP maximum data size. 


The Pv field is interpreted as an unsigned integer that is transferred most 
significant byte first (big endian). Values lie in the range 1 through (2432)-1. 
Leading zero bytes may be truncated. 
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The default value for this parameter is 0 and arises only when either the 
Parameters field is absent or the MaxSduSize parameter is absent from the 
Parameters field. 


MaxSduSize should never be sent with an explicit value of zero’. Zero is 
the default value which arises when the parameter is absent Connect 
TTP-PDUs. 


The default value of zero for MaxSduSize disables the operation of 
Segmentation and Reassembly. All outbound Data TTP-PDUs should be sent 
with the M bit cleared. The ™ bit is ignored on all inbound Data TTP-PDUs. The 
size of TTP-SDU passed as the UserData parameter in TTP_Data service 
primitives will be constrained to fit within a single Data LM-PDU. 


1 to (2°? — 2) Values between 1 and (232-2) inclusive specify the maximum size in bytes of 


ey 


TTP-SDU that may be delivered to the end of the connection sending the 
Connect TTP-PDU that carries the MaxSduSize parameter. 


Specifies an unbounded MaxSduSize. In general, this indicates that TTP entity 


sending this parameter AND the corresponding TTP client are capable of 
receiving arbitrarily large SDUs. This is like to require that the implementation 
of the TTP entity supports the delivery of partially reassembled TTP-SDUs and 
that the TTP client is capable of processing partially delivered TTP-SDUs so 
that buffers may be recycled. 


2.4 Detailed Operation 


The operation of the TTP involves the exchange of Data TTP-PDUs described in Section 2.3.1. 
Effectively this adds a single octet of header to the IrLMP LM-MUX Data LM-PDUs. This additional 
octet is used to convey increments (credits) to the number of Data TTP-PDUs that may be 
exchanged in each direction using the underlying LM_Data service. 


3 This is to ensure that LITE implementations of TTP that do not support SAR NEVER have to 
inspect the value of the MaxSduSize parameter, they merely have to test for its presence. 
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TTP_Data.request(data) 


TTP_Data.indication(data,status)) 
Segmentation 


if TTP_Segment[M=m,UserData=data] eet RxSDU.data 4 TTP_LocalFlow.request(flow) 
xX Buller 


TxQueue | == Basi Reassembly Buffer i RxSDU.busy = (flow==off) 
é 
AvailCredit += 7 4 


!RxSDU.busy 
SendCredit += deltacredit 


SendCredit>O <«. 
——— | RxQueue 
RemoteCredit - = 1; 


TTP_Segment[M=m,UserData=data] 


AvailCredit 


as] 
2 
1s} 
2 
is} 
& 
o 
xc 


SendCredit -= 1 ” 
LM_Data.request( y LM_Data.indication( 
TTP_PDU(deltaCredit,data)) TTP_PDU(deltacredit,M=m,UserData=data) ) 


LM_MUX Connection 
Endpoint 


Figure 2.4 Tiny TP SAR and Credit Flow 


Figure 2.4 shows the manipulation of both inbound and oubound credit at one end of a TTP 
connection that has reached its data phase. 


For the purposes of describing the operation of Tiny TP, Figure 2.4 and Table 2-1 (below) describe 
a buffer management scheme that assumes a fixed number of receive buffers is available to the 
connection and that available credit is advanced the peer TTP entity in an aggressive way. 
However, other buffer management policies are legal. 


Possible variations include: 


e dynamic variation of the number of receive buffers in use by a TTP connection. 
NB. Once credit has been advance to a peer (ie. transfered from AvailCredit to 
RemoteCredit) it cannot be reclaimed. 


e¢ alazy policy for advancing credit. In the context of the description given, this means that credit 
is held longer at on AvailCredit rather than being advanced at the eariliest opportunity. This 
leaves buffers available to be reclaimed (from AvailCredit) and redeployed to other needy 
TTP connections or to relieve resource problems elsewhere in a system. 


Note that Connect TTP-PDUs exchanged during connection establishment are not regarded as 
requiring or consuming credit. During connection establishment the use of segmentation and 
reassembly is indicated as are any constraints on the maximum Service Data Unit (SDU) that can 
be conveyed using the TTP_Data service. 


The TTP entity manipulates variables associated with each TTP-Connection that implicitly encode 
the state of the flow control mechanism for that connection. The mechanism is described in the 
Event/Action pairs of Table 2-1 (below). 


2.4.1 Variables 
AvailCredit Credit available to advance to the peer TTP entity. 
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Credit held by peer TTP Entity: 


SendCredit Credit held by local TTP Entity 

Connected A flag that monitors the state of the underlying LM-MUX connection. 

TxQueue FIFO queue used to hold TTP_Segments and TTP_Disconnect requests. Holds 
segmented SDUs and prevents a disconnect overtaking queued data. 

RxQueue FIFO queue used to hold inbound TTP_Segments and TTP_Disconnect 
requests. TTP_Segments are transferred from RxQueue to the reassembly 
buffer, RxSdu.data. Credit is recycled as this transfer takes place. 

MaxSegSize The maximum size of segment conveyed in an outbound Data TTP-PDU. 

TxMaxSduSize Received from peer TTP entity during connection establishment. Used to guard 
the size of TTP-SDUs submitted using the TTP_Data.request service primitive. 

RxMaxSduSize Transmitted to peer TTP entity during connection establishment. Used to police 
the size of inbound TTP-SDUs. 

RxSdu.size The current size of a partially received SDU undergoing reassembly. 

RxSdu.data The current partially received SDU undergoing reassembly. 

RxSdu.busy A flag that controls the consumption of the receive queue. Set/cleared by 


invocation of TTP_LocalFlow.request. 


2.4.2 Credit Operation 


If SendCredit is non-zero then the local entity may reliably send data. While SendCredit is zero 
TTP_Data.request primitives are left queued in sequence on TxQueue awaiting credit from the 
peer entity. 


If RemoteCredit is non-zero then the peer entity is able to reliably send data. 


If AvailCredit is non-zero then the local entity has credit available that it has not yet advanced to 
its peer. Credit is advanced in blocks of up to 127 with the normal flow of data. 


If RemoteCredit falls below some configured LowThreshold and AvailCredit is or becomes non- 
zero whilst TxQueue is empty or SendCredit is zero, then RemoteCredit is advanced by the 
transmission of a dataless FlowData TTP-PDU. 


2.4.3 Segmentation and Reassembly 


When Segmentation and Reassembly (SAR) is disabled in a given direction then all SDUs 
exchanged must fit within a single Data TTP-PDU. In this case the M bit is ignored on reception. 


When SAR is enabled and a received SDU exceeds the maximum SDU size indicated during 
connection establishment the resulting SDU is truncated and the truncated portion delivered 
(logically) when the final segment arrives with a status code that indicates that an error has 
occurred. 


In the formal description that follows it should be noted that it is assumed that data is delivered to 
the TTP client only on reception of the last segment of an SDU subjected to SAR. 


This may not be the case in some practical interfaces which allow the delivery of partially 
reassembled SDUs in the interests of economising on buffer space. This latter style of interface is 
capable of supporting unbounded SDU sizes. See Section 4.1 for more discussion of Tiny TP 
receive buffering strategies. 
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2.4.4 Event/Action Table 


TTP_Connect.request( Connected=False; AvailCredit=0; RxMaxSduSize=mSduSize; 
CalledTTPSAP=sap-id, RxSdu.size=0; RxSdu.busy=False; 
RequestedQos=qos, 
MaxSduSize=mSduSize n= DEFAULT_INITIAL_CREDIT /* Local Policy */ 
UserData=data) 
RemoteCredit=0; SendCredit=0; 
if(n>127) { AvailCredit=n-127; n=127 } 
RemoteCredit=n; 


if( mSduSize == 0 ) 
ttpPdu = 
ConnectTTP-PDU( P=0,|InitialCredit=n,UserData=data ): 
else 
ttpPdu = 
ConnectTTP-PDU ( P=1, InitialCredit=n, 
Parameters={(PiMaxSduSize,mSduSize)} 
UserData=data ); 


LM_Connect.request ( 
CalledLsap=sap-id, RequestedQos=qos, ClientData=ttpPdu 
TTP_Connect.response( AvailCredit=0;RemoteCredit=0; RxMaxSduSize = mSduSize; 
CallingLSAP=sap-id RxSdu.size = 0; RxSdu.busy = False 
MaxSduSize=mSduSize 
UserData=data ) n= DEFAULT_INITIAL_CREDIT /* Local Policy */ 


if(>127) { AvailCredit=n-127; n=127 } 
RemoteCredit=n 


if( mSduSize == 0 ) 
ttpPdu = 
ConnectTTP-PDU( P=0,|nitialCredit=n,UserData=data ): 
else 
ttpPdu = 
ConnectTTP-PDU ( P=1, InitialCredit=n, 
Parameters={(PiMaxSduSize,mSduSize)} 
UserData=data ); 


LM_Connect.response( 
CallingLsap=sap-id, RequestedQos=qos, ClientData=ttpPdu ) 
Connected=True; 
TTP_Disconnect.request(UserData=data ) AppendTail(TxQueue, 
TTP_Disconnect, UserData=data 
TTP_Data.request(UserData=data) ~ Error; 
sizeof(UserData)==0 v !Connected 
TTP_Data.request(UserData=data) ~ IISAR Disabled 
TxMaxSduSize == 0 Error 
sizeof(UserData)>(MaxSegSize) A Connected 
TTP_Data.request(UserData=data) ~ /ISAR Enabled 
TxMaxSduSize # 0 A Error 
sizeof(UserData)>TxMaxSduSize ~ Connected 
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TTP_Data.request(UserData=data) ~ 
TxMaxSduSize == 0 « sizeof(UserData)>0 ~ 
sizeof(UserData) <= MaxSegSize ~ Connected 
TTP_Data.request(UserData=data) ~ 
TxMaxSduSize # 0 A sizeof(UserData)>0 
( TxMaxSduSize == UnBounded v 
sizeof(UserData) < TxMaxSduSize ) A 
Connected 


TTP_UData.request(UserData=data) 
!Connected 
TTP_UData.request(UserData=data) 
Connected 
TTP_LocalFlow.request(Flow=flow) 


LM_Connect.indication( 
CallingLsap=sap-id, ResultantQos=qos, 
ClientData=ConnectTTP-PDU 
[P=0,InitialCredit=n, 
UserData=data] ) 


LM_Connect.indication( 
CallingLsap=sap-id, ResultantQos=qos, 
ClientData=ConnectTTP-PDU 
[P=1,InitialCredit=n, 
Parameters=plist, 
UserData=data] ) 


LM_Connect.confirm( 
CalledLsap=sap-id, 
ResultantQos=qos, 
ClientData=ConnectTTP-PDU 
[P=0, InitialCredit=n, 
UserData=data] ) 
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/! SAR Disabled queue as a last segment. 
AppendTail(TxQueue 

[TTP_Segment,M=0,.UserData=data] ) 
// SAR Enabled 


NumSegs = INT ((sizeof(data)+MaxSegSize-1) / MaxSegSize) 


// Queue all but the last segment 
for(i=1;i<NumSegs;i++) { 
AppendTail(TxQueue, 
[TTP_Segment, M=1, GetSegment( i,data )] 
} 


/! Queue the last segment of the SDU 
AppendTail(TxQueue, 

TTP_Segment, M= 
Error 


LM_UData.request(ClientData=data) 


if (flow == on) 
RxSDU.busy = false; 
else 
RxSDU.busy = true; 


SendCredit = n; TxMaxSduSize = 0 
MaxSegSize = MaxTxlrLapDataSize-3 


TTP-Connect.indication( CallingTTPSAP=sap-id, 
ResultantQos=qos, 
MaxSduSize=TxMaxSduSize, 
UserData=data ); 

SendCredit=n; TxMaxSduSize = 0 


MaxSegSize = MaxTxlrLapDataSize-3 


for ( each (pi,pv) in plist) 
if (pi==PiMaxSduSize) 
TxMaxSduSize = pv; 


TTP-Connect.indication( CallingTTPSAP=sap-id, 
ResultantQos=qos, 
MaxSduSize=TxMaxSduSize, 
UserData=data ); 

SendCredit=n; TxMaxSduSize = 0; 


MaxSegSize = MaxTxlrLapDataSize-3 


TTP_Connect.confirm(.CalledTTPSAP=sap-id, 
ResultantQos=qos, 
MaxSduSize=TxMaxSduSize 
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P| Connected True: 


LM_Connect.confirm( 
CalledLsap=sap-id, 
ResultantQos=qos, 
ClientData=ConnectTTP-PDU 
[P=1, InitialCredit=n, 
Parameters=plist, 
UserData=data] ) 


LM_Disconnect.indication( Reason=r, 
ClientData=data ) 


LM_Data.indication( 
ClientData=FlowData TTP-PDU 
[M=m, DeltaCredit=n, 
UserData=data] ) A 
sizeof(UserData)== 
LM_Data.indication( 
ClientData=FlowData TTP-PDU 
[M=m, DeltaCredit=n, 
UserData=data] ) A 
sizeof(UserData) > 0 


Head(TxQueue)== 
[TTP_Disconnect, UserData=data] 


Head(TxQueue) == 


[TTP_Segment, M=m, UserData=data] 


SendCredit>0 


( Empty(TxQueue) v SendCredit==0 ) A 
RemoteCredit<=LowThreshold A 
AvailCredit>0 ~ 

Connected 


SendCredit=n; TxMaxSduSize = 0; 
MaxSegSize = MaxTxlrLapDataSize-3 


for ( each (pi,pv) in plist) 
if (pi==PiMaxSduSize) 
TxMaxSduSize = pv; 


TTP_Connect.confirm(.CalledTTPSAP=sap-id, 
ResultantQos=qos, 
MaxSduSize=TxMaxSduSize 
UserData=data); 

Connected=True; 

Connected=False; Flush(TxQueue); 

/* Queue inbound disconnect to allow buffer data to drain */ 

AppendTail( RxQueue, 

TTP_ Disconnect, Reason=r, ClientData=data] ): 

/* Dataless FlowData TTP-PDU */ 

SendCredit = SendCredit+n; 


/* Deal with the inbound Credit */ 
SendCredit = SendCredit+n; RemoteCredit = RemoteCredit-1; 


/* Put Received Segment on Rx Queue */ 
AppendTail(RxQueue,[TTP_Segment, M=m, Userdata=data]) 


LM_UData.indication(ClientData=data TTP_UData.indication(UserData=data 


Connected=False; 

Flush(TxQueue); Flush(RxQueue); 

LM_Disconnect.request( Reason=UserRequested, 
ClientData=data ): 


n=AvailCredit; AvailCredit=0; 
If(n>127) { AvailCredit=n-127; n=127 } 
RemoteCredit=RemoteCredit+n; 
SendCredit=SendCredit-1; 
LM_Data.request( ClientData= 

Data TTP-PDU 

[M=m, DeltaCredit=n,UserData=data] ) 

DeQueueHead(TxQueue 
/* Send a Dataless FlowData TTP-PDU */ 


n=AvailCredit; AvailCredit=0; 
If(n>127) { AvailCredit=n-127; n=127 } 
RemoteCredit=RemoteCredit+n; 


LM_Data.request( ClientData= 
Data TTP-PDU 
M=0, DeltaCredit=n,UserData=NULL 
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Head(RxQueue) == /* Non-terminal SDU Segment */ 
[TTP_Segment, M=1, UserData=data | A RxSdu.size=RxSdu.sizetsizeof(data); 
RxMaxSduSize # 0 A 
!RxSdu.busy if( RxSdu.size<=RxMaxSduSize v 
RxMaxSduSize==UnBounded) { 
RxSdu.data = Reassemble(RxSdu.data, data); 


} 


/* Recycle Segment Buffer */ 
DeQueueHead(RxQueue) 
AvailCredit = AvailCredit+1; 
( Head(RxQueue) == /* Last SDU Segment or Inbound SAR disabled*/ 
[TTP_Segment, M=0, UserData=data] ~ 
!RxSdu.busy ) v RxSdu.size=RxSdu.sizetsizeof(data) 


( Head(RxQueue) == if( RxSdu.size<=RxMaxSduSize v 
[TTP_Segment, M=m,UserData=data] ~ RxMaxSduSize==UnBounded v 
RxMaxSduSize ==0 ) A RxMaxSduSize==0 ) 
!RxSdu. busy ) RxSdu.data = Reassemble(RxSdu.data, data); 
TTP_Data.indication(UserData=RxSdu.data, Status=OK); 
}else { 
TP_Data.indication( UserData=RxSdu.data, 
Status=Truncated ); 


} 


/* Recycle Segment Buffer */ 
DeQueueHead(RxQueue) 
AvailCredit = AvailCredit+1; 
Head(RxQueue) == Flush(RxQueue); /Should be empty anyway */ 
[TTP_Disconnect, Reason=r, ClientData=data] ~ | TTP_Disconnect.indication(Reason=r,ClientData=data); 
!IRxSdu.bus 


Table 2-1 Tiny TP Entity - Event Action Table 
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3. IrLMP IAS Object and Attributes 


3.1 Exported Attributes 


This section defines an attribute that is intended for use in the definition of object classes which 
represent service providers that make their service available via a TTP entity. 


Use of this attributes is not mandatory, but its use is strongly encouraged in those circumstances 
where an attribute is required for the same purpose as this attribute is defined. 


IrDA:TinyTP:LsapSel Integer The value carried in this attribute identifies the IrLMP LSAP/TTPSAP of the 
TTP entity that provides access to the service represented by the containing 


object 


Legal values are restricted to the range 0x01 -Ox6f. 
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4. Appendix A Implementation Considerations 


4.1 Tiny TP Buffering. 


The description of Tiny TP given in Section 2.4 explicitly includes both segment buffering, the 
receive buffer pool and the RxQueue and a SAR Reassembly buffer (the variable RxSDU). 


4.1.1 Receive Buffer Pool 


The receive buffer pool and receive queue shown in Figure 2.4 may be implemented as a circular 
buffer as shown below. 


Figure 4.1 Receive Buffer Pool 
Organisation 


If this is implemented as a circular list rather than an array, its size may be altered dynamically, 
provided buffers are added or removed in the current AvailCredit region. 


Note that Tiny TP can function with a single buffer in this receive buffer pool. However, a single 
TTP connection cannot then take full advantage of the underlying IrLAP window, except for an 
IrLAP window size of 1. If resources allow the size of the TTP receive buffer pool for a TTP 
connection should be at least equivalent to the size of the current IrLAP receive window. In this 
way a single TTP connection can the entire IrLAP window. Additional credit up to twice the IrLAP 
window size enables the connection to make smooth progress without the need to rapidly advance 
fresh credit as inbound PDUs are consumed and buffer space recycled. 


Thus a TTP receive buffer pool size of twice the IrLAP receive window size should allow a Tiny TP 
connection to progress smoothly. Nevertheless, even with a TTP receive buffer pool size of just 1 
TTP will function, although progress is unlikely to be smooth. 


4.1.2 SAR Reassembly Buffer 


The description of Tiny TP given in this document also explicitly includes a per TTP connection 
SAR reassembly buffer. However, if the API exposed by an implementation of Tiny TP supports 
the partial delivery of SDUs then this buffer is entirely unnecessary. Buffering of inbound PDUs is 
all this is required ie. the receive buffer pool described in the previous section. Buffers from the 
RxQueue section of the pool may be delivered to the TTP client, thus freeing them to collect more 
data segments. 


Thus a implementation of Tiny TP with minimal buffering requirements would provide paritial SDU 
delivery and use a single TTP-SDU buffer per receive buffer pool. 
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Another observation that may assist the implementor is that inbound Data TTP-PDUs need only be 
buffered on RxQueue whilst the SAR reassembly buffer is unavailable. If the SAR buffer is 
available, the data carried a freshly delivered PDU may be transferred directly. 


4.1.3 Combined Buffer Pool and SAR Reassembly Buffer 


Another alternative for reducing the amount of buffer space require for TTP is to combine the 
buffer pool and the SAR buffer. Referring to Figure 4.1 above, the RxQueue segment performs the 
function of the SAR buffer. In this case received Data TTP-PDUs are packed into the receive 
buffer and the total size of the pool must equal or exceed that of client specified maximum receive 
SDU size. Credit is only advanced as the amount of space under the ‘AvailCredit’ portion 
successively exceeds integer multiples of the current maximum segment size. If the entire buffer 
become filled with an incompletely reassembled SDU truncated delivery should occur (freeing the 
buffer space) and resynchronisation is then accomplished at the next SDU boundary. 


4.2 Closing TTP Connections 


Tiny TP does not implement graceful disconnect. However, under normal circumstances, a 
TTP_Disconnect.request will be invoked from one end of a TTP connection. Data in the 
reverse direction may be lost if it has not all been delivered to a TTP client. However, data 
previously send by the TTP client that initiates the disconnect will be delivered before the 
corresponding TTP_Disconnect .indication is delivered to the peer TTP client. 


If TTP disconnect can be initiated from either end then it is necessary for TTP clients to ensure that 
it is safe to close a TTP connection. Implementors of TTP clients should be aware that if no 
measures are taken in the application protocol to ensure that it is ‘safe’ to close a TTP connection 
(eg. an exchange of “I’m Done’, “So am |” messages) prior to the invocation of 
TTP_Disconnect.request data may be lost in EITHER direction. 


4.3 Byte Stream v Sequenced Packet Service 


Strictly, Tiny TP offers a sequence packet service. Even if MaxSduSize are allowed to default 
during connection establishment then SDU boundaries are still maintained, however the SDU is 
constrained in size to fit within a single maximum sized Data TTP-PDU. 


Thus with SAR disabled, TTP may be used to implement either: a sequenced packet service, 
where SDU boundaries are preserved between TTP peers but the maximum SDU size is 
constrained by the maximum sized Data TTP-PDU; or a byte-stream service where there is no 
guarantee that SDU boundaries are preserved between peer TTP clients. 


Implementors of TTP clients should be aware of this distinction, particularly in cases where the 
relative alignment of SDUs and PDUs is important to the operation of the application protocol. 


